home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1112 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.2 KB
  1. Subject: Re: GEM-List 
  2. Date: Fri, 29 Jul 1994 16:09:59 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6. Mark Baker wrote:
  7. >[GEM++] crashes on my Falcon as well, as I've already emailed you about. The
  8. >editable fields in Nethack crash as well. Could this be a conflict with LTMF?
  9.  
  10. It certainly is.  A pervious version of GEM++ used the ED_START objc_edit
  11. operation.  GEM ignores this operation, and it is documented as Do Not Use.
  12. LTMF crashes if it is used.  It's hard to say which is at fault, in this
  13. case - but it doesn't matter, because GEM++ doesn't do it anymore.  Simply
  14. turn off the extended editor, and it works fine.  What can I say - I don't
  15. use LTMF and I didn't see the Do Not Use until more recently.
  16.  
  17. > > I know it might be hard to resist thinking of one's own machine as the
  18. > > target for one's software and optimizing for that, but this really must
  19. > > be avoided, especially by anyone want to follow a standard.
  20. >
  21. >But surely optimising for STs, TTs and Falcons, with or without Overscan,
  22. >Blowup etc, is better than optimising for graphics cards which a tiny minority
  23. >have.
  24.  
  25. Including Falcons in 256 colours and in TrueColour?  Use offscreen bitmaps
  26. in those resolutions and you are talking major expense (640x480 - a small
  27. offscreen bitmap - is almost a megabyte in Falcon HiColour).
  28.  
  29. I'm not totally adverse to offscreen bitmaps.  Just be extremely careful
  30. about when to use them.  Don't just use them because it is easier.
  31.  
  32. >Pointer form change I would definitely support and it _has_ been around since
  33. >day one. But not the others.
  34.  
  35. Point-to-type:      TOSWIN, UW.
  36. Exit highlighting:  Menu items (since day one)
  37.  
  38. >were it not totally different to GEM conventions. As for exit highlighting I
  39. >can't see any point in it, although it is harmless. It doesn't look very nice
  40. >with 3d buttons though.
  41.  
  42. Depends on the highlighting, probably.  Motif uses an outline as the highlight.
  43. I don't really like it either, except for menus.
  44.  
  45. >Balloon help... why not, it's a pity there isn't an
  46. >efficient way to track menus (it can be done using timer events)
  47.  
  48. Not true.  Rectangle events are provided to the application EVEN WHILE
  49. THE MENUS ARE BEING USED.  Strange, but true.  (I can see it is going
  50. to cause be problems, as the drop-down menus don't clip the rectangle
  51. lists!)
  52.  
  53. >If anyone wants to deviate from the standard by, for example, using
  54. >their own fileselector, click to type in background windows or any other thing
  55. >by all means have it as a user option (and certainly don't force it on the
  56. >user). But don't say we all have to have it as an option, it's just your
  57. >non-standard program.
  58.  
  59. Only the name for these options needs to be standardized - just so that
  60. anyone who DOES want to provide them knows of a defined way to allow the
  61. user to disable it.
  62.  
  63.  
  64. >But I agree with your proposal, it would make sense to do this. How about
  65. >putting everything in the multitos folder though?
  66.  
  67. Hehe... it's the old story.  A War to End All Wars.  The Folder to End all
  68. Folders.  Alas, a Geneva user would look pretty silly creating a C:\MULTITOS
  69. folder.
  70.  
  71. A C:\SYSTEM or C:\SYS folder is the best we can do.  Recommend putting
  72. C:\CPX and C:\GEMSYS and C:\SPEEDO there and re-directing the
  73. appropriate pointers.  
  74.  
  75. --
  76. Warwick
  77.